Add ACP provider plugins: Copilot, Droid, and Auggie - #118

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

Thanks for the submission — we really want to get this in. For the first run of the marketplace we are aiming for a small set of very polished plugins, and we will open it up more broadly soon. Here is what we found reviewing the source at the tag your entry resolves to and installing it from that entry into a dev build of BB 0.40:

Thanks for these three — a family of ACP providers is exactly the kind of thing we want in the marketplace, and the code itself is clean: no network calls, no process execution, no secret access, clean SVGs, no lifecycle scripts, every dependency from registry.npmjs.org. If the only question were "is this safe", the answer is yes.

The problem is that they do not work on the BB release the marketplace serves.

Blocker 1: none of the three registers anything on BB 0.40

All three install into a dev build, and the background service logs registered acp-<name> — but no provider appears. server.ts:124-127 writes modelCli: { selectFlag, primaryModels } with no listArgs. Since 0.40 the customAcpAgents array is consumed only by the first-party provider-acp plugin, which parses each entry with a schema built from experimental_acpLaunchSpecSchema, where listArgs: z.array(z.string()) is required. The entry fails with modelCli.listArgs: expected array, received undefined and parseCustomAcpAgents then skips it entirely. (bb <name> status does correctly report NOT registered — that part works.)

The three installs land in needs-configuration on our Linux dev host because the vendor CLIs are absent, which is expected — but even with the CLIs present, the provider would not appear.

Blocker 2: they build on a mechanism BB removes in 0.41

customAcpAgents is deprecated. BB "still reads that array ... logs a deprecation warning for each one, and never writes to it" (docs/configuration.md:367-377), and LEGACY_CUSTOM_AGENTS_REMOVED_IN = "0.41". These plugins write to it. engines.bb: ">=0.39" therefore over-claims compatibility.

The fix we would like

Port to bb.providers.register(...) plus the published ACP kit @get-bb/plugin-sdk/provider-bridge/acp. BB 0.40's headline provider change was exactly this, there is a reference doc at docs/provider-plugin-api.md, and the first-party plugins/provider-acp is a working exemplar whose README explicitly says "a third-party plugin adds an ACP agent exactly the way this one does, with no bb-side code." You are also pinned to @get-bb/plugin-sdk@0.4.8, which predates PluginProviders entirely; current is 0.4.24+.

Worth knowing: a user can already add Auggie today with
bb plugin config provider-acp set customAgents '[{"id":"auggie","displayName":"Auggie","command":"auggie","args":["--acp"]}]'
with no plugin at all. So the value these plugins add is packaging and discoverability — which makes it more important that they use the supported path.

The copilot id is contested

PR #95 (balazstasi) also claims entries/copilot.json, submitted 5 days earlier, MIT-licensed and unit-tested. We are not awarding the id to either submission yet, because both write to the deprecated customAcpAgents array and neither uses bb.providers.register. We would like to give it to whichever ships a provider-API implementation first, with #95 holding priority on a tie as the earlier submission.

One thing we should raise directly rather than leave unsaid: there are some unusually specific idiom overlaps with #95's public repo, which was public 5 days before bb-copilot was created. A byte-identical error sentence — `${configPath} must contain a JSON object; refusing to overwrite it` (#95 src/config-entry.ts:71-73, yours server.ts:78) — plus an identical dataDir fallback expression, the same "provision" service name, and the same ${configPath}.<plugin>-${process.pid} temp-file shape. That phrase appears nowhere in BB's source, docs or authoring skill, so it is not shared boilerplate. It is equally consistent with two coding agents converging from the same docs/configuration.md chapter, and we note bb-auggie/bb-droid were created two weeks before #95 — so the project clearly predates it. We are not making an accusation; we would just like your answer on the record before merging anything under that id.

Smaller things

• The logo field is a no-op. withoutLegacyLogo strips logo from every legacy entry, so installLogo() (server.ts:95-102) writes <bb-data-dir>/logos/<id>.svg for nothing.
• Lost-update race on ~/.bb/config.json. provision() (server.ts:104-138) does read-modify-write with no locking. This PR ships three plugins that all start provision at load — each reads the same snapshot and the last renameSync wins, silently dropping entries. That file also holds machineCredential. No credential is read or transmitted; the risk is destructive, not exfiltration.
• primaryModels is fictional or unverifiable (server.ts:26) and gets dropped anyway, since modelCli only survives when listArgs.length > 0. A hardcoded model list BB then discards is misleading in the UI.
• findBinary (server.ts:58-64) searches PATH plus ~/.local/bin, ~/.npm-global/bin, /opt/homebrew/bin, /usr/local/bin unconditionally and writes the first hit's absolute path into config as the command BB spawns with agent privileges. On hosts where /usr/local/bin is group-writable that is a weak local-hijack path.
• Wrong path check. server.ts:52 tests existing.command.includes(delimiter) where delimiter is the PATH separator (:), not sep (/). On POSIX an absolute command never matches, so a hand-set command is silently re-resolved on every reload.
• bb <name> status can throw — readConfig at server.ts:220 is outside any try/catch, unlike the repair/unregister branches.
• Dead shell scripts. scripts/install.sh / uninstall.sh are the pre-plugin manual integration and are never invoked. Shipping an installer that hand-edits the host config is confusing weight.
• No LICENSE file in any of the three repos.
• Name the vendor in each entry description. None of the three says whose service a user's code and thread content will be sent to (Augment Code / GitHub-Microsoft / Factory.ai). We would like that stated.
• droid's assets/logo.svg has no viewBox, so it will not scale into an icon slot. All three logos use a hardcoded fill rather than currentColor, so they will not follow light/dark.

Auggie is ready for a re-check.

Published ai-ecoverse/bb-auggie@v0.2.0 and updated this listing:

• Registers through the ACP plugin customAgents setting instead of the deprecated customAcpAgents array, so acp-auggie actually appears on bb 0.40.
• Drops modelCli (Auggie's model list output is not the line format bb parses); the picker catalog comes from the ACP session.
• Icon is now currentColor (icons/auggie-758c27ad.svg) so the marketplace/plugin mask is fully opaque in light and dark themes.
• Locally: bb auggie status reports the provider registered, and bb provider models acp-auggie returns the live catalog.

Copilot and Droid in this PR are still on the 0.1.0 path that fails the listArgs schema. I only shipped the Auggie port in this pass.

Factory Droid 0.2.0 is tagged at https://github.com/ai-ecoverse/bb-droid/releases/tag/v0.2.0 and this listing now tracks ^0.2.0.

That release addresses the 0.40 load failure and the icon notes from the review:

• Stopped writing customAcpAgents. The plugin upserts only its own row in the ACP providers customAgents setting, which re-registers immediately and does not need modelCli.listArgs.
• Dropped the invalid modelCli / primaryModels block and the no-op logo copy.
• Icon is a currentColor mask with a viewBox (vendored as icons/droid-0f671277.svg).
• Description now names Factory.ai.

Verified on bb 0.40.0: droid@0.2.0 is running and bb provider list shows acp-droid / Factory Droid.

Still outstanding relative to the requested provider-API port: this release uses the documented ACP customAgents setting rather than bb.providers.register + @get-bb/plugin-sdk/provider-bridge/acp. Copilot is unchanged at v0.1.0. Ready for a re-check on Droid and Auggie.

Copilot and Droid are on the same 0.40 path as Auggie now.

• ai-ecoverse/bb-copilot@v0.2.0 — customAgents registration, no modelCli, currentColor icon. Locally acp-copilot is registered and lists GPT/Claude models from the ACP session.
• ai-ecoverse/bb-droid@v0.2.1 — adds the theme-aware provider mark on top of the 0.2.0 customAgents port. Locally acp-droid is registered and lists Factory models.

Marketplace listings now point at currentColor icons (copilot-bbc37c3b.svg, droid-0f671277.svg) and Copilot/Droid ranges are ^0.2.0 so a 0.40 install cannot land on the broken 0.1.0 tags.

Ready for a re-check of all three.

Refreshed all three listings.

• Copilot's entry is now gh-copilot (ai-ecoverse/bb-gh-copilot, v0.4.0). Add plugin entry: copilot #95 submits a different plugin for the same agent as copilot, and both entries would have been the same file — renaming ours lets the two merge independently.
• Droid and Auggie point at fresh v0.3.0 releases. Auggie's range was ^0.1.0, which never resolved past the 0.1.0 line.
• All three: no more fallback to the deprecated customAcpAgents array when the provider-acp settings read races its factory at boot, declared native skill roots, permission modes mapped to real vendor flags, vitest coverage, MIT license.

npm run check passes with liveness against the new tags.

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

The maintainer accepted the reported notes. The exact entry installs, and the refreshed validation job passed. I removed the blocked label.

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

The refreshed validation job passed. I merged this submission. Thank you for the contribution.